1. Field of the Invention
The present invention relates to a device and a method for processing a program code as may particularly be used for processing program code of object-oriented programming languages.
2. Description of Related Art
Software programs require structuring of the source code. Structuring of this kind is supported by object-oriented programming languages by class definitions. It is achieved by means of classes that a program code may be re-used and that a program is structured such that diagnosis and service are made easier considerably. In object-oriented programming, the class is an abstract generic term for the description of a common structure and a common behavior of objects. The structure of a class is defined via attributes and the behavior is defined via methods, also called operation, function and procedure. Objects generated from classes are referred to as examples or instances of the class. In some programming languages, there is a certain object for each class serving to represent the class at run time and being responsible for generating objects of the class and calling correct methods.
When compiling a source text, in some programming languages or environments, it is not a machine code which is established directly, but an intermediate product, the so-called byte code or intermediate language code. This intermediate code is usually machine-independent and relatively compact compared to the source text and to the machine code.
Java is one of today's best-known examples of a byte code-based programming language. Other languages employing byte codes are, for example, C# or Delphi.NET.
A so-called virtual machine, in the case of Java, Java VM, executes the intermediate code. Executing the intermediate code by the virtual machine is time-intense. Special just-in-time compilers (JIT compilers) translate byte code bits into corresponding machine code pieces once during program execution and then execute same. In this way, the execution times, but not the starting times may often be forced into the region of pre-translated machine codes.
FIG. 7 shows a comparison of a source code program 702 and an intermediate code program 704 generated from it. The intermediate code 704, which is also referred to as byte code or intermediate language, is generated from the source code 702 by a compiling process 706.
In the source code 702, an FOR-loop is passed and a count is output with every pass. A subprogram or a method WriteLine is called for outputting the count.
This stack-oriented intermediate code 704 does not yet consist of machine instructions. The structure of the source code 702 from which the intermediate code 704 has been generated may still be recognized. In particular, the subprogram call WriteLine and the FOR-loop realized by a return may be recognized.
In object-oriented programming language, methods or procedures are frequently called, wherein it is not possible to determine the procedure called without considering the object reference associated to the method call. For managing the methods in object-oriented programming languages, tables calling an association between class-specific methods and comprising the pertaining procedures are thus generated. When so-called virtual methods are called, the compiler does not store the address of the method in a program code, but manages these methods in a separate table, the so-called virtual method table (VMT). Only the address of the virtual method table is stored in the pertaining object. The compiler causes an extra VMT to be formed in the memory for each class when executing the program. All the virtual methods of this class are entered in this table, together with their addresses. Instead of calling virtual methods, the compiler generates intermediate program code looking in the VMT which method is really to be called for the respective object. Thus, not the data type of the reference (class) but the data type of the object is used for identifying the VMT. Calling the method via the VMT will consequently always result in the correct method. This calling is also referred to as late binding because the program to be executed determines the address of the method at run time.
FIG. 8 shows the structure of a virtual method table and its relationship to the object instance. The virtual method table 812 is a read-only look up table comprising a field of pointers and being generated for each class of a source program when compiling the source code and being stored in the instruction space of the programmer.
The virtual method table 812 comprises four methods associated to a class. The methods are methods VirtualMethod 1 to 4. The method call in the source program 813 is illustrated in the intermediate code as a pointer 814 pointing to the object 816 from which the method has been called. The source program 813 comprises a method call for the method VirtualMethod 1. The term VirtualMethod 1 may be an index or offset serving to determine the actual location of the subprogram address. The object 816 comprises a VMT pointer pointing to the virtual method table 812. The virtual method table 812 thus allows selecting the correct method when calling a method. This is important because there may be different methods for different classes, or which, however, have been given the same method name. Consequently, it is not possible without the virtual method table 812 to associate the correct method to a method call.
A dynamic method table DMT is generated for each class declaring new dynamic methods or inherited dynamic methods. The dynamic method table is much smaller than the virtual method table and only stores special information on dynamic methods of a class.
FIG. 9 shows the structure of a dynamic method table DMT 912b and its relationship to the object instance 816 and the virtual method table 912a. 
FIG. 10 shows the .NET technology by the software producer Microsoft in detail .NET is a set of software technologies consisting of, apart from a virtual run time environment, a frame work of class libraries and services serving as the basis for self-developments. The so-called Common-Language Specification defines a common subset of binary code, which may be translated from the virtual run time environment into the machine code of a destination machine and then be executed by the destination machine. Thus, it is possible to program NET by different languages. Visual Basic.NET, Visual C#.NET or Visual C++.NET are, for example, available as languages. A source program 702 established in these languages is converted to an intermediate code 704, the so-called binary code, according to the Common Language Specification by a compiler 706. It is tried by means of different techniques to keep the negative impact of the run time of a program on the program speed as small as possible. Available for this is a just-in-time compiler JIT 1022 translating the binary code 704 into a machine-executable machine code 1024. The just-in-time compiler offers a middle course between interpreting and compiling the binary code 704. In addition, further programming languages may be employed where the compiler directly generates the machine code 1026. This machine code 1026 will then be executed on the operating system bypassing the intermediate step via the binary code 704.
As can be seen from FIG. 7, the source code and, in particular, the object structures in the code represent the intellectual property and the economic value of a software program. Performance and code effectivity are directly dependent on the optimum definitions of classes and objects. The intermediate code will always contain the data and object structures of the source code. Object-oriented high-level languages distributed in the form of intermediate code, such as, for example, Java, C#, Delphi.NET, thus offer less protection against disassembly than a 100% compiling language.
In contrast to the prior art Windows environment where a user obtained an executable machine code as an *.exe file, an intermediate code is given to the user in the novel NET environment. In the machine code of the *.exe file, the so-called native code, a connection to the high-level language data structure has been dissolved as far as possible. Consequently, there is no direct relation between the machine code and source code objects, data structures and methods.
Thus, in the prior art Windows environment, the intellectual property of the software developer has been protected by the compiling process because the user of the *.exe file could not become aware of internal program structures.
In the novel .NET environment, the intellectual property of the software developer is no longer protected by a compiling process because the binary code 704 is provided to the customer in the .NET environment instead of the machine code.
When providing intermediate code, a software producer is at risk of a user of the intermediate code to do reengineering and thus to be able to produce the software used by himself or imitate and distribute data structures.
In large programs, re-naming of subprogram calls already offers protection against reconstructing the original source code. With lower security requirements, this may already be considered as sufficient protection of the source code.